DNS: The blind spot of PCI DSS

If you thought that, by implementing all PCI DSS controls, you were going to be invulnerable against cyberattacks, you may need to review your strategy. There are certain technical areas that are not covered by that standard and that need to be reviewed in detail. One of them (and perhaps the most important): the name resolution infrastructure (DNS).

The payment card industry's data security standard (Payment Card Industry Data Security Standard – PCI DSS) defines a series of physical, logical and administrative controls for the protection of payment card data, with particular emphasis on the Primary Account Number (Primary Account Number – PAN).

In technical terms, PCI DSS includes explicit references to security controls such as firewalls (firewalls), firewalls Web Application (Web Application Firewalls – WAF), anti-malware, File Integrity Monitoring (FIM), intrusion detection and prevention systems (IDS/IPS), time synchronisation services (NTP), event logging (logs), use of secure versions of protocols (such as TLS, for example), etc. However, specific controls are not included for one of the critical components of a network architecture: the Domain Name System (Domain Name System – DNS). And it is precisely in the DNS service that a ‘blind spot’ can be found in compliance with the standard.

Introduction to DNS service

To get into context, DNS is a distributed, hierarchical database that uses the client-server model and allows you to associate a domain name (known as Fully Qualified Domain Name – FQDN) and other associated data (known as “records”) with an IP address. The technical description of the concepts, implementation criteria and specification of the name resolution system can be found in the RFC1034 y RFC1035.

Generally speaking, there are 5 main elements within a name resolution system:

• Client: Component within a client machine that makes name resolution requests for its operation (browsers, email clients, etc.).
• DNS Resolve (also known as “appeal” or “iterator”): Server in charge of receiving client requests for name resolution. Uses temporary storage of already resolved records (caching) to optimise response times.
• Root nameserver: Server in charge of providing the name and IP address of the authorized server of the highest level area of the searched domain. Currently they exist 13 servers of this kind in the world.
• TLD (Top Level Domain) nameserver: Server that holds information for all domain names that share a common domain extension, such as .com or .net. There are several types of TLD servers, including generic or gTLD (.com, .net, .edu, .org and .gov) and country or ccTLD (.uk, .co, .jp, .es, etc.). The full list can be consulted here.
• Authoritative nameserver: Server that contains the domain-specific information it manages (e.g. yahoo.com) and returns the IP address of the specified host name to the DNS Resolve who made the initial request.

Example of the name resolution process

Like many other services that were part of the origins of the internet, DNS was developed in order to be operational and scalable, but security was not part of these initial criteria: there was no authentication, the integrity of the responses was not validated and the data was transmitted in clear text, deficiencies that began to be exploited by attackers through the following techniques:

• DNS spoofing / cache poisoning: In this attack, falsified DNS data is entered into the cache of the DNS Resolve, which makes the solve returns an incorrect address for a domain, diverting traffic to a malicious machine or any other place the attacker wants, in order to distribute malware or collect login data.
• DNS Tunneling: This technique allows the encapsulation of other protocols (such as SSH or HTTP) in DNS requests in order to avoid restrictions at the packet filtering level, used to data exfiltration or for communication with command and control servers (Command and Control – C&C).
• DNS hijacking: Using this technique, the attacker redirects queries to a different domain name server using malware or modifying the DNS server.
• Reflection/amplification and denial of service attacks (DoS/DDoS): In these attacks, the name resolution infrastructure is used to generate malicious traffic aimed at specific targets or to saturate the service. Some of these best-known attacks within this category are NXDOMAIN, Phantom, Random subdomain, domain lock-up, botnet-based CPE, etc.

DNS and its relationship with PCI DSS

As indicated above, the PCI DSS standard does not include any explicit reference to the use of security controls in the name resolution infrastructure, so during a formal implementation or compliance assessment, the following questions may arise that may affect the safety of the environment:

• Can the DNS protocol and its standard port (53/UDP) be considered “secure”?
• Is it necessary to implement additional security considerations in a traditional name resolution infrastructure?
• Is the designation of a specific name resolution server required within a network that processes, stores and/or transmits payment card data?
• How should the connection between a client and a DNS server be made to resolve names in a PCI DSS-aligned environment?
• What criteria should be used when choosing an authoritative name resolution server?
• Are the root and TLD servers at the top of the DNS hierarchy reliable?
• Should name registration service providers be listed as PCI DSS service providers?

Currently, many of these questions do not have a formal answer. This makes it quite likely that the vast majority of PCI DSS compliant environments have minimal or insufficient controls in place to protect their domain name resolution infrastructure from attack.

In that regard, here are a number of recommendations to protect DNS services from the payment card environment, complementing the basic requirements of PCI DSS:

Considerations for registering domains linked to PCI DSS environments

Another major problem not addressed by the PCI DSS standard is managing the security of domain registries linked to PCI DSS environments, registered with external name registry providers, especially in e-commerce services.

As described above, DNS allows you to associate an IP address with a domain name (FQDN). When a user (an individual or an organisation) wants to register a domain name under a specific TLD, they must contact an authorised entity called a “registrar” (register). This registrar receives the user's registration request, validates that the domain is available and, if it is, proceeds to add the new name to its DNS records database. From that moment, any change that is required to be made to the registry (renewal, transfer or even editing of DNS records and of zones , if these tasks have been delegated to the registrar) shall be performed by means of the interfaces provided by this provider.

If you register a domain name that points to the IP address of an asset within a PCI DSS environment, the registrar automatically becomes a critical element of the organization's infrastructure, as the responsibility for the operation and management of that name rests with this entity. If an attacker compromises the registrar's network or unauthorizedly accesses the domain management interface, traffic can be redirected to malicious servers without the end user noticing the change.

According to the PCI SSC Glossary, a service provider is defined as “a commercial entity that is not a payment brand, directly involved in the processing, storage or transmission of cardholder data on behalf of another entity. This also includes companies providing services that control or could affect the data security of cardholders. Examples include managed service providers offering managed firewalls, IDS and other services, as well as hosting providers and other entities”.

Generally, a domain registrar is not considered among the service providers that affect a PCI DSS environment – even though its services may affect the data security of cardholders – so there is no obligation for these entities to comply with the standard or to add additional security controls to prevent the risks associated with domain management.

In this regard, it is recommended to follow these recommendations:

• Using a domain registrar reliable.
• Minimize the information exposed in the Whois database (information of domain owners) through private registration services.
• If available, enable multifactor authentication (MFA) in the domain management interface provided by the registrar to minimize unauthorized access.
• Manage the different roles and permissions of users who can access DNS management interfaces.
• Enable DNS change blocking (DNS change locking), which adds additional controls when making changes to registered domain names. For example, an employee of the domain registry company may request written or telephone authorization from an authorized person of the company to make changes to the DNS, request a personal identification number (PIN), an OTP code, etc.
• Restrict access to domain management interfaces only to authorized IP addresses, physical locations, or specific devices.
• Enable notifications (by email, SMS, etc.) when DNS changes are made.
• Set up auto-renewal to prevent a malicious user from acquiring the domain when it expires and redirect traffic to servers under their control.
• Regularly monitor DNS records (especially CNAMEs) for inactivity or obsolescence issues that could lead to a malicious user taking control of subdomains (subdomain takeover).

Conclusion

“A chain is as strong as the weakest of its links”. We have heard this phrase many times applied to the field of cybersecurity and it has not yet lost its validity.

An environment that processes, stores and/or transmits payment card data must comply with the controls of the PCI DSS standard, which adds an additional layer of security to protect such data. However, one of the components of these environments that is generally not properly identified or protected is the Name Resolution Service (DNS). As a result, the organisation may have a ‘blind spot’ in its security strategy, so it is essential to implement preventive and corrective actions so that this does not become a risk vector.

The use of a secure architecture, the implementation of additional security features and the protection of DNS records displayed on the internet, as well as the use of DNS services provided by trusted entities are part of this strategy to defend this ‘weak link’. All of these recommendations should be integrated as a complementary part of PCI DSS controls in organizations that must meet this standard.

Dan J. Bernstein (DJB) announced a series of vulnerabilities in the DNS system in 1999 And no one listened to him. Dan Kaminsky found a serious vulnerability in the DNS system in 2008 and saved the Internet. Let's not make the same mistakes again …